Designers Corner with Prof. Mike Smith  Part 1  Part 2

Prototype design decisions

Over the first few weeks of the summer, Hamish and I completed the design of our first prototype.

We decided to take the approach of using a PHY (physical layer) chip together with an FPGA. The PHY chip is the tire of the Internet, interfacing between the cables (roads) and digital logic (car) that handles the data. Other alternatives we had considered were using a combination PHY and MAC (media access controller) chip. You could think of the MAC as the transmission using our car/road analogy to the Internet. The problem with the combination PHY/MAC chips is that most of them were intended to interface to a PC, and these PHY/MAC chips thus used either an ISA bus or PCI bus interface. That would mean we would have to build an ISA bus or PCI bus controller on the FPGA. These bus interfaces are readily available for FPGAs (in fact this is a very popular application for Xilinx FPGAs), so we spent some time exploring this option. The most important decision, though, was whether to use a processor to handle the TCP/IP stack or not. Hamish decided fairly early on that he wanted to try and avoid using a processor and experiment with using the FPGA to handle the TCP/IP stack function that would normally be handled by software. Given that we would not be using a processor (though we realized we could change this decision at a later point) we decided it made more sense to use a PHY chip without the MAC, since we wouldn’t have a processor bus. Dave Van den Bout had already begun the design of a prototyping board using a Xilinx Virtex FPGA and an Ethernet interface using a PHY chip so Dave’s thinking also influenced us.

The next decision was on how to perform configuration and reconfiguration using the Internet. Remember a Xilinx FPGA is volatile, so that when power is removed the configuration disappears. One of the driving forces behind the project was to demonstrate the use of Internet Reconfigurable Logic (IRL) to configure an FPGA attached to the Internet without a PC. Xilinx FPGAs are built to configure from serial ROMs (read-only memories), but not over the Internet. The fixed logic that is built into the Xilinx FPGAs cannot handle this, so we needed to add some fixed logic outside the FPGA. Some work at Xilinx had already been performed in this area. A group had already constructed a test board that used a Xilinx nonvolatile CPLD (complex programmable logic device) alongside a Xilinx Virtex FPGA to perform configuration from Flash or EPROM. Hamish used this as the basis of our configuration solution.

Reconfiguration of a Xilinx Virtex FPGA from EPROM or Flash memory. The FPGA is volatile and needs to be configured at power on. The fixed logic in the nonvolatile CPLD provides an address counter to the EPROM or flash memory to cycle through all the configuration data in memory.

We weren’t finished yet, though. This CPLD plus EPROM or flash memory solution gave us the ability to configure from memory, but we still had to get the configuration data, the bitstream, from over the Internet into memory. There are several ways to achieve this, and, since we designed the original scheme that we used, we have come up with a few more. Our first design used the Virtex FPGA to configure and reconfigure itself. There would be an initial configuration loaded into the flash memory or EPROM, a sort of bootstrap. The analogy with a conventional software bootstrap is fairly close. When a PC starts up a small piece of code, called the bootstrap, is loaded from the boot sectors of your hard disk before anything else. The PC software bootstrap is responsible for loading the rest of the PC operating system. In a similar fashion, after the FPGA loads the bootstrap code it is ready to communicate over the Internet. Our next decision was how to receive new configuration data over the Internet. Hamish decided to store the received data in SRAM, wait until the bitstream was complete, and than have the FPGA initiate the configuration of itself, in a very similar manner to the initial bootstrap. Hamish added two banks of SRAM to hold the bitstream, (one bank as a spare) with each bank capable of holding an entire configuration bitstream.

We also considered how to debug our prototype board. Remember we didn’t plan to use a processor in our design. Debugging was going to require some careful thought since we couldn’t use conventional techniques used in embedded systems. Hamish, Brandon, and I spent quite a while on this topic and decided on a combination of LCD panel to get simple results out quickly and a parallel port for any more extensive data input and output we might need to perform. Apart from a few more straightforward details, such as power supplies, we were now ready to design the first prototype.

Table of Contents   Previous   Next